It's a bit subtle/weird that this will count as matching, but won't have actually set derived_field. I guess it might just need calling out a bit more clearly in a comment or something?

I wonder if we need a test to confirm that having multiple rules where the first rule does this behaves as we expect? e.g. only have optional fields for the first rule, but then confirm it does/doesn't interfere with later rules?

yeah matching doesn't necessarily imply it will take action, because the condition check is quite a complex boolean ((old.required OR new.required) AND (old.another OR new.another)). It's more of a pre-check for when it could conceivably be relevant

I would expect the conditional clauses for using this action would be should for all the contributing fields, and must_not for the derived field itself

I can add some tests for when there's multiple UpsertCondition in the overall configuration, to check that subsequent rules do/don't match depending on the outcome of an earlier concat action.

But the other issue, making the conditions accurately match only when the concat action will actually be able to set the derived field, I don't think we can achieve that with the current condition matching logic: it's not expressive enough to handle nested AND/OR conditions that we'd need. Effectively we'd need the condition matching to do the same old/new fallback logic that the action currently implements.